-
Notifications
You must be signed in to change notification settings - Fork 516
preventing unnecessary emitting in edge driver #2357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
preventing unnecessary emitting in edge driver #2357
Conversation
|
Channel deleted. |
Test Results 69 files 449 suites 0s ⏱️ Results for commit d6c703e. ♻️ This comment has been updated with latest results. |
|
zigbee-contact_coverage.xml
zigbee-lock_coverage.xml
zigbee-presence-sensor_coverage.xml
zigbee-thermostat_coverage.xml
zwave-sensor_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against d6c703e |
| device:emit_event(capabilities.lock.lock.unlocked()) | ||
| if device:get_latest_state("main", capabilities.lock.ID, capabilities.lock.lock.NAME) == nil and device:supports_capability(capabilities.lock) then | ||
| device:emit_event(capabilities.lock.lock.unlocked()) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add test case not to send initial value when driver is switched?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related TCs have been updated~
f00dae9 to
cf912ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
9db44b6 to
253f560
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me.
.../SmartThings/zwave-sensor/src/fibaro-door-window-sensor/fibaro-door-window-sensor-2/init.lua
Outdated
Show resolved
Hide resolved
48ff16b to
e17e0ea
Compare
| local function emit_event_if_latest_state_missing(device, component, capability, attribute_name, value) | ||
| if device:get_latest_state(component, capability.ID, attribute_name) == nil and device:supports_capability(capability) then | ||
| device:emit_event(value) | ||
| end | ||
| end | ||
|
|
||
| local function emit_component_event_if_latest_state_missing(device, component, capability, attribute_name, value) | ||
| if device:get_latest_state(component.id, capability.ID, attribute_name) == nil and device:supports_capability(capability) then | ||
| device:emit_component_event(component, value) | ||
| end | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, device:emit_event(value) means device:emit_component_event("main", value).
Do we need to divide as two functions?
And let me see the device:emit_component_event()
It seems like the function is already checking supports_capability.
I am not sure we need to check supports capability in these drivers or not? How about you @pInksenberg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree with you, when calling device:emit_event(value) , it actually calls device:emit_component_event("main", value), which checks supports_capability internally, and I believe that supports_capability can be ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I'll combined these two functions into one.
|
can you describe driver list or event list for this PR to commit message in more detail? |
0a7afb1 to
af6f071
Compare
updated! |
af6f071 to
f678380
Compare
…witch-over.
We add check_latest state before sending initial event(open/unlocked/presense) for following drivers:
- SmartThings/zigbee-contact/src/aqara/
- SmartThings/zigbee-lock/src/samsungsds
- SmartThings/zigbee-presence-sensor/src/arrival-sensor-v1
- SmartThings/zigbee-presence-sensor/src (top-most driver)
- SmartThings/zigbee-thermostat/src/aqara
- SmartThings/zwave-sensor/src/fibaro-door-window-sensor/fibaro-door-window-sensor-1
- SmartThings/zwave-sensor/src/fibaro-door-window-sensor/fibaro-door-window-sensor-2
f678380 to
d6c703e
Compare
Check all that apply
Type of Change
Checklist
Description of Change
There’re VoCs about ZigBee Things reported from Korean Market while user is doing switchover, a device event emitting may be called to initialize device state from edge driver to cloud, so an unexpected routine could be triggered and make user confused.
we change the driver code to avoid emitting unnecessary event during the hub switch-over by checking the latest state, only focus on the important(security related) events, 'open', 'present', 'unlocked'.
Summary of Completed Tests